Submissions

1. Overview

1.1 Introduction

This section explains the end-to-end component submission workflow for Financial Institution (FI) users within the Developer Console.

The Developer Console provides a structured and secure platform that enables FI users to:

• Create and manage their own dedicated private GitHub repository.
• Submit components (Aspects & Widgets).
• Track the complete lifecycle of submissions, including validation, review, and deployment.
• Engineering and security teams reviewal through GitHub PR workflows.
• Publish validated components to the Staging Experience Group.
• Deploy published components to the Production Experience Group.
• Manage collaborators and access controls securely.

2. Login and Default Admin Setup

2.1 New FI – Admin Behavior

When a new FI is onboarded:

• A default Admin user is created by the Candescent onboarding team.
• Only users with Admin and Developer roles can access the Submissions tab.
• Spectators cannot view or access the Submissions tab.

3. First-Time Setup – Build Component (New FI Only)

3.1 Build Component

To build a new component, follow the steps:

1. Click the Submissions tab from the left navigation pane.

2. Click Build Component.

When clicked:

• Repository creation, team setup, and user assignment to the team are completed in the backgorund.
• The user receives an email to Accept Invitation for the GitHub repository.
• Access is granted after accepting the invitation.

4. Component Submission Form (UI Flow)

After clicking Build Component, the user is redirected to the Component Selection dialog.

4.1 Component Selection

1. Users can select the component to submit using the radio button.
2. Users need to follow the instructions and complete the next steps to submit.

4.2 Submission Form Capabilities

1. After clicking Proceed in the Component Selection dialog, the user is redirected to the Component Submission form.
2. Select Component Type
   • Dropdown selection (e.g., Aspect)
3. Select Platform
   • Web
   • Mobile
4. Provide Code

   • For Aspects only, enter either JavaScript code directly in a textbox

     OR

   • For Aspects & Widgets, select an existing GitHub PR dropdown (if already created)

5. Provide Metadata (Example - Component Name)

4.3 Action Buttons

1. Cancel

• Displays the Are you sure you want to submit your component for review? dialog.
• Redirects user back to Submission Dashboard.
• For Aspects, if a user provides the code as a code snippet, no submission will be created.
• For widgets, the metadata will not be updated for the submission.

2. Submit for Approval

• System validates all required fields.
• For Aspects, a PR is created and linked to the metadata.
• For Widgets, the metadata is added to the PR.
• User is redirected to Submission Dashboard.
• Newly submitted component appears in the list.

5. Submission Dashboard

After submission (or for already onboarded FIs), users will see the Submission Dashboard.

5.1 Dashboard Features

• View all submissions.
• Search by component name.
• Filter by:
  • Status
  • Timeline
• Click on a component to view details.

5.2 Component Details View

The following timeline structure(s) are displayed:

Stage	Description
In Review	Submission created. Security scans are in progress, and the submission is under review.
Engineering Validation	Code is being reviewed by the engineering team.
Security Assessment	Security validations are in progress or completed.
Published to Stage	Component successfully published to the staging environment.
Deployed to Production	Component successfully deployed to the Production environment.

You can also:

• View GitHub reviewer comments within the UI.
• Click Read More to navigate to GitHub.
• Click GitHub links to open the PR(s) directly.

5.3 Editing Metadata and Production Deployment

• Users can update a submission’s metadata before merging the PR by selecting Edit from the submission’s three‑dot menu.
• Once the component status is Published, users can deploy it to Production by selecting Deploy from the three-dot menu.

6. Environment Isolation & Deployment

6.1 Default Behavior

• All submissions are published to the Staging Experience Group by default.
• When a user submits a component through the Developer Console, it is not directly deployed to Production.
• Instead, after successful validations and approvals, the component is first published to the Staging Experience Group.

This ensures:

• Safe testing and validation before production rollout.
• Reduced risk of introducing issues into the Production environment.

Important Notes

Staging acts as a pre-production environment where users can verify functionality before deployment.

6.2 Deployment Actions

Once a component reaches the Published status, it becomes eligible for deployment to Production.

• A Deploy button is available in the three-dot menu for each eligible submission on the dashboard.
• The button is enabled when the status is Published or if there is a failure while publishing to the Staging Experience Group.
• For all other statuses, the Deploy button remains disabled.

Once Deploy is clicked:

• The system initiates the deployment process.
• The component is moved from Staging to Production Experience Group.
• The deployment is completed as part of the same action.
• The Deploy button is disabled after deployment to Production, indicating that the process is complete.

Important Notes

Deployment marks the final step in the submission lifecycle and makes the component live in the Production environment of the experience group.

6.3 Access of Staging Experience Group

• Access to the Staging Experience Group is managed separately by the DSM (Delivery/Support Management) team.
• The Developer Console does not manage or grant access permissions to Staging Experience group.

If a user does not have access:

• They may not be able to view or validate the component in Staging.
• Once the status is Published, users can deploy the component to the Production Experience Group by selecting Deploy from the three-dot menu on the dashboard.

Important Notes

Users should coordinate with their DSM team to request access to the Staging environment if required.

7. Role-Based Access in Developer Portal & Repository Permissions

7.1 Roles with access to the Submissions tab:

Role	Access
Admin	Full access
Developer	Submit and view
Spectator	No access

7.2 GitHub Team Requirements

Even if a user is an Admin or Developer of the Developer Portal:

• They must be part of the FI GitHub team.
• If not part of the GitHub team:
  • They can only view the dashboard.
  • The New Submission button is disabled.
  • They cannot view PR details or create submissions.

7.3 Restrictions

• Users cannot access other FI repositories.
• Each user has access only to their own FI private repository.

8. Manage Collaborators

Only Admin users can manage collaborators (i.e., add and remove collaborators).

8.1 Admin Capabilities

In the Manage Collaborator tab:

Admins can:

• Add users by entering email address.
• Remove collaborators
• View details:
  • FI ID
  • FI Name
  • GitHub Repo URL
  • Action column

8.2 Developer Restrictions

• Developers cannot add or remove collaborators.
• The Manage button is disabled for developers.

8.3 Adding a Collaborator

When an Admin adds a user:

1. The user must already exist in User Management (with an Admin or Developer role).
2. The user receives a GitHub invitation email.
3. After accepting the invitation, the user gains access to the FI private repository.

9. PR Workflows & Approvals

9.1 Workflow Stages

Once a submission is created, the workflow stages are:

Stage	Description
Review	PR created, scanning initiated, or updated with reviewer comments.
Revisions	Changes requested by reviewers; update the PR and resubmit.
Approved	All scans passed and approvals from Engineering and Security completed.
Published	Component successfully published to the Staging Experience Group.
Deployed	Component successfully deployed to the Production Experience Group.
Failed	Submission failed due to scanning or publishing issues.
Closed	PR closed without merging; submission no longer active.

9.2 User Capabilities During Review

• Users can edit the code in the GitHub PR.
• Users can merge the PR only after obtaining engineering and security team approvals.
• Users cannot assign reviewers.

10. Email Notifications

Users receive email notifications for:

• PR creation
• Security scanning results
• Engineering validation updates
• Security assessment updates
• Reviewer comments
• Approvals
• Merging PR

11. Publishing & Deployment Flow to Experience Group

Once a component is:

• Approved by engineering team
• Approved by security team

Then:

• The user can publish the component or merge the PR.
• The component is listed in the Staging Experience Group of the Admin Portal.
• The status updates to Published.
• Once the component is in the Published status, the user can trigger deployment to the Production Experience Group using the Deploy button.

12. Already Onboarded FI Scenario

If the FI is already onboarded and has submitted a component before:

• After login, the user can view the Submission Dashboard.
• All submissions for the FI (across users) are made visible.

13. Security & Isolation

• Each FI has a dedicated private repository.
• No cross-FI visibility.
• Role-based UI restrictions are enforced.

14. Troubleshooting Submission Failures

If a submission fails, check the GitHub Action logs for the specific cause of the failure. The logs will indicate whether the issue is a configuration error, a validation failure, or an Aspect limit violation.

14.1 Aspect Limits

Each Experience Group has a defined limit on the number of Aspects it can contain. If a submission fails due to a limit violation:

• Remove an existing Aspect that is no longer needed.
• Re-run the GitHub Action job.
• To increase your Aspect allocation, contact your DSM.

15. Known Issues (Planned for Future Release)

• Misleading notification text: The dialog currently displays the text: "Run npm install --legacy-peer-deps within the widget folder of the widget you created in your private repository." This instruction only applies to mobile widgets and is not required for web widgets. The verbiage will be updated in a future release to clearly distinguish between widget types and avoid confusion for end users.
• Slight lag in status updates: Users may experience a slight lag in the UI when the system refreshes the status after an operation is performed. A fix to improve responsiveness will be included in a future release.
• Verbiage improvements for toast notification and in-app messages: Toast notifications and in-app messages will be revised for clarity and consistency. The updated text will help users better understand system responses and eliminate silent failures by surfacing appropriate feedback for all actions.

16. Additional Support

For questions or issues related to the Submission Portal, contact [email protected].

Next Steps

To search and discover details around Marketplace Products, visit Marketplace Product Catalog.